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SYSTEM AND METHOD OF SKINNING THEMES 

[0001] The present patent disclosure relates generally to a communications system 
for providing communications to a plurality of devices and specifically to a system and 
method of skinning themes. 

[0002] A portion of the disclosure of this patent document contains material which is 
subject to copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent disclosure, as it appears in 
the Patent and Trademark Office patent files or records, but otherwise reserves all 
copyrights whatsoever. 

BACKGROUND 

[0003] Scalable Vector Graphics (SVG) is an extensible markup language (XML) 
markup for describing two-dimensional vector graphics. An application may use an SVG 
file to represent its user interface (UI). This SVG file can be referred to as the 
application's "skin". Basic graphical UI requirements include the fact that an application 
must be able to graphically represent its status and react to input from the graphical user 
interface. The application should be able to: 

a) react to user input from the GUI. Without this, applications will be limited 
to passively representing status. Most applications require some form of user 
interaction. 

b) graphically reflect status to the user. Without this an application will not be 
able to represent status related to the business logic. The UI will be limited to 
accepting user input. Most applications have a requirement to display 
information about their status to the user. In general, both a) and b) must be 
satisfied. 

[0004] Traditional application graphical user interfaces are hard-coded along with the 
application logic. That is the look and behavior of the user interface is programmed with 
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the application logic in a program like Java or C++ and embedded along with the 
application. 



SUMMARY 

[0005] An embodiment of the present disclosure relates to a media engine for 
creating a graphical interface for an application on a device. The media engine comprises 
an interaction interface for notifying the media engine of changes to the application, a 
renderer for rendering the graphical interface, and a parser for parsing, from a template 
file, template information for controlling how the renderer renders the graphical interface. 

[0006] A further embodiment of the present disclosure relates to a media engine for 
creating a graphical interface for an application on a device. The media engine comprises 
an interaction interface for notifying the media engine of changes to the application, a 
Tenderer for rendering the graphical interface, a parser template information from a 
template file, and a layout manager for dynamically controlling the length of at lest one 
data element object of the set of data element objects. The template information 
comprising a set of data element objects and a set of custom event objects. The template 
information for controlling how the Tenderer renders the graphical interface. 

[0007] A further embodiment of the present disclosure relates to a mobile 
communication device comprising a display, an operating system, an input device, at 
least one application, at least one template file, and a media engine. The media engine 
comprises an interaction interface for notifying the media engine of changes to the at 
least one application, a renderer for rendering the graphical interface on the display, and a 
parser for parsing, from the at least one template file, template information for controlling 
how the renderer renders the graphical interface on the display. 

[0008] A further embodiment of the present disclosure relates to a method of 
skinning an application on a device comprising the steps of parsing a template file, 
storing the parsed information in a template, receiving updated data element information 
from an application through an interaction interface, updating the template with the 
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received updated data element information, controlling the length of the data element 
information using a layout manager, passing the template to a Tenderer, and rendering the 
template as a graphical interface. 

[0009] A further embodiment of the present disclosure relates to a propagated signal 
carrier carrying signals containing computer-executable instructions that can be read and 
executed by a computer, the computer-executable instructions being used to execute a 
method of skinning an application on a device comprising the steps of parsing a template 
file, storing the parsed information in a template, receiving updated data element 
information from an application through an interaction interface, updating the template 
with the received updated data element information, controlling the length of the data 
element information using a layout manager, passing the template to a renderer, and 
rendering the template as a graphical interface. 

[0010] A further embodiment of the present disclosure relates to a computer-readable 
medium storing instructions or statements for use in executing in a computer a method of 
skinning an application on a device comprising the steps of parsing a template file, 
storing the parsed information in a template, receiving updated data element information 
from an application through an interaction interface, updating the template with the 
received updated data element information, controlling the length of the data element 
information using a layout manager, passing the template to a renderer, and rendering the 
template as a graphical interface. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[001 1] An embodiment of the patent disclosure will now be described by way of 
example only with reference to the following drawings in which: 

Figure 1 shows in a functional schematic an example of a mobile device, in 

accordance with an embodiment of the present patent disclosure; 
Figure 2 shows in a functional schematic an example of an application, in accordance 
with an embodiment of the present disclosure; 
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Figure 3a shows in a functional schematic an example of a media engine, in 

accordance with an embodiment of the present disclosure; 
Figure 3b shows in a functional schematic another example of a media engine, in 

accordance with an embodiment of the present disclosure; 
Figure 3c shows in a functional schematic another example of a media engine, in 

accordance with an embodiment of the present disclosure; 
Figure 3d shows in a functional schematic another example of a media engine, in 

accordance with an embodiment of the present disclosure; 
Figure 4 shows in a pseudo code listing an example application, in accordance with 

an embodiment of the present disclosure; 
Figure 5a shows in a flow chart an example of a method for creating a graphical 

interface associated with an application, in accordance with an embodiment of the 

present disclosure; 

Figure 5b shows in a flow chart another example of a method for creating a graphical 
interface associated with an application, in accordance with an embodiment of the 
present disclosure; 

Figure 6 shows in a screenshot an example of a Today style home screen view, in 

accordance with an embodiment of the present disclosure; 
Figures 7a, 7b and 7c illustrate in screenshots examples of calendar integration into a 

home screen skin, in accordance with an embodiment of the present disclosure; 
Figures 8a and 8b show in screenshots examples of phone integration into the home 

screen skin, in accordance with an embodiment of the present disclosure; 
Figure 9 shows in a screen shot an example of SMS and MMS integration into the 

home screen, in accordance with an embodiment of the present disclosure; 
Figure 10 illustrates an example of the concept of a Home Screen area inside 

Organize Applications, in accordance with an embodiment of the present 

disclosure; 

Figure 1 1 shows in a detailed block diagram an example of a preferred handheld 
device adapted in accordance with an embodiment that may be used as an 
electronic device having message and organization system functions and a home 
screen GUI in accordance with an embodiment of the present disclosure. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

[0012 J A goal of skinning is to separate the presentation (GUI) of the application 
from the business logic (functionality) and allow the GUI to be defined through some 
external file which can be created and "late bound" to application code. In order to allow 
this late binding there must be a common understanding or contract between the 
application logic and the skin. An interface must be defined, that the application can 
interface with, to control the UI and a skin must be created that satisfies this interface. 

[0013] The present disclosure provides a skinning themes document for skinning 
themes for an application. The skinning themes document comprises at least one data 
element representing data generated by an application and at least one custom event 
representing events generated by the application. The interface that allows for the late 
binding of the GUI defined by the skinning theme document to the application 
information, that is the data elements and the custom events, is provided by a media 
engine. 

[0014] Embodiments of the present patent disclosure will now be described with 
reference to various examples of how the embodiments can best be made and used. For 
convenience, like reference numerals are used throughout the description and several 
views of the drawings to indicate like or corresponding parts, wherein the various 
elements are not necessarily drawn to scale. 

[0015] Figure 1 shows in a functional schematic an example of a mobile device 100, 
in accordance with an embodiment of the present patent disclosure. Mobile device 100 
comprises a display 101, an input device 102, an operating system 103, various 
applications 105, a media engine 1 10a and a template library 115. Although multiple 
applications may be present on the mobile device, the following description describes a 
mobile device that has only a single application 105. The template library 115 may 
include multiple template files. Alternatively a single template file may be used in place 
of the template library 115. Examples of an application 105 include a home screen 
application, a calendar application, an email application, a time application etc. 
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[0016] Figure 2 shows in a functional schematic an example of an application 1 05, in 
accordance with the present disclosure. The application 105 is a collection of at least 
application code 106 that performs some business logic, and application data elements 
107 that the application code 106 can manipulate or modify. The application 105 works 
in conjunction with the media engine 1 10a to display application information on the 
display of the device. In addition to the business logic the application code 106, also 
includes content interaction logic or code 108. This content interaction code 
communicates with the media engine 1 10a in order to notify it of updates to data 
elements 107, or the occurrence of custom events. The communication is represented 
schematically by 109. The communications informing the media engine of updates to 
data elements 107 is shown as 109a, and the communications informing the media engine 
of the occurrence of custom events is shown as 109b. 

[0017] Figure 3a shows in a functional schematic an example of a media engine 1 1 0a, 
in accordance with the present disclosure. The media engine 1 10a includes a renderer 

1 1 1 for rendering the graphical interface to the device display, content interaction APIs 

1 12 for interfacing with the application 105, a template 1 13 for holding the graphical 
interface information, and a parser 1 14 for parsing the graphical interface information 
from a template file. Although the media engine 1 10a creates a template 1 1 3 for holding 
the template information that is parsed from the template file, it could alternatively use 
the information directly from the parser 114, without the intermediate template 113. 

[0018] One approach to skinning is to define a scalable vector graphics (SVG) 
document which acts as a template file for the user interface for the application. More 
specifically, in order to satisfy both requirements of reacting to user input and graphically 
reflecting the application status, a mechanism for implementing a contract between an 
SVG template document and application code 106 is developed. In one embodiment the 
application 105 is responsible for handling user input and the media engine 1 10a is 
responsible for defining and displaying the graphical interface 120. To graphically 
reflect the application status, the application code 106 defines a set of "data elements" 
and "custom events" that represent specific data and events that are generated by the 
application 105. A data element 107 is some information that the application 105 
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manipulates or modifies and can be presented on the graphical interfaced . A data 
element 107 is assigned a name which is a string. A custom event is some event of 
significance that occurs in the application's business logic which may need to be 
reflected in the graphical user interface 120. Similar to data elements 107, custom events 
are assigned a name which is a string. It is not the responsibility of the application 105 to 
define what user interface changes occur as a result of these events, or how to display the 
information of data elements 107. The application's responsibility is to inform the media 
engine 1 10a whenever it needs to update the information associated data elements 107 
and when custom events occur. 

[0019J In one embodiment the template file defines the custom events and data 
elements that are displayed in the graphical interface. The application code 106 
determines what application data elements 107 or custom events (which may include user 
input events) to bind to the data elements and events defined in the graphical interface. 

(0020) A skinning themes document is written for an application 105 using the names 
of the data elements 1 07 and the names of the custom events. The skinning theme 
document, or template file, describes how to display the information associated with the 
data elements 107 and custom events. 

[0021 J The media engine 1 1 0a acts as an interface between the application 1 05 and 
the graphical interface template file. The application 105 notifies the media engine 1 10a 
of updates to data elements 107 and the occurrence of custom events. The media engine 
1 10a uses the skin template file to define how to display this information on the display 
101 . Using the skin document as a template, the media engine 1 10a, or more particularly 
the renderer 1 1 1 of the media engine 1 10a, renders the graphical interface 120 to the 
display 101. 

[0022] The media engine 1 1 0a uses the template file for describing how to render a 
graphical interface 120. The media engine may use a parser 1 14 to parse the template 
information form the template file and store it in a template 1 13 that is accessible to the 
media engine 1 10a. If the template file describes the graphical interface 120 using a 
markup language, then the parser 1 14 would be able to read the markup language and 
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store the template information in the template 113. For example, if the template file 
defines the graphical interface 120 in SVG, then an SVG parser would read the template 
information in the SVG file and store the parsed information in a template 113. The 
parser may be referred to as a transcoder since it translates the template file code into 
code representing the template 113. The template 113 holds the template information in 
a form expected by the media engine 1 1 0a and the Tenderer 111. As previously 
described, the template 1 13 is not required. It is possible for the parser 1 14 to provide the 
template information directly to the media engine 1 10a or the Tenderer 111. 

[0023] The media engine 1 1 0a described above is not involved in the processing of 
user input. It receives a template file defining a graphical interface 120, and notifications 
from an application 105 regarding data elements 107 and custom events. In the above 
example an application 1 05 would be responsible for handling user input. This may be 
accomplished by interacting with functionality provided by an input device driver, with 
operating system functionality, or other methods as may be known. 

[0024] Figure 3b shows in a functional schematic another example of a media engine 
1 10b, in accordance with an embodiment of the present disclosure. The media engine 
1 1 0b further includes a layout manager 1 1 8 for optionally controlling the display of 
template information. 

[0025] Figure 3c shows in a functional schematic another example of a media engine 
1 1 0c, in accordance with another embodiment of the present disclosure. The media 
engine 1 10c is similar to the media engine 1 1 0a previously described, however media 
engine 1 10c also has an event engine 1 17. The event engine 1 17 adds functionality to the 
media engine 1 10c. It can provide user input control. An application 105 that makes use 
of the event engine's 1 17 user input features can include code to notify the application 
1 05 of any user input. Those skilled in the art will appreciate that many different forms 
of user input are possible. An application 105 may be notified in different manners. 

[0026] An application 1 05 may notify the event engine 1 1 7 that it wishes to be 
informed when ever a user input occurs. This notification can be achieved by an API call 
to the content interaction APIs 1 12b of the media engine 1 10c. The content interaction 



-8- 



WO 2007/131359 PCT/CA2007/000864 

APIs 1 12b would include additional calls for providing the user input control to an 
application 105. The call should include information the event engine 1 1 7 can use to 
notify the application 105. This information can include the application identifier, the 
function that the event engine 1 17 is to call when an event occurs. The call may also 
indicate the types of user input events the application 105 is interested in. For instance an 
application 1 05 may only wish to be notified of input from a scroll wheel, or from a 
keyboard, or pointing device, etc. When ever a user input event occurs the event engine 
117 checks to see if any applications 105 are to be notified, and if there are any, it sends a 
notification of the event. 

[0027] An application does not necessarily need to notify the event engine 1 1 7 that it 
wishes to receive notification of input events. Alternatively the application may poll the 
event engine 1 1 7 to determine if an event has occurred, and if one has to receive it. The 
application would make a call to a content interaction API 1 12b querying or requesting 
an user input event. 

[0028] As described above an application 105 in accordance with the present 
disclosure may obtain user input in various ways. The above description can also apply 
to not only user input events but also to system events or other generated events. For 
example an application 105 may register with the event engine 1 1 7 through the content 
interaction APIs 1 12b to receive notification each time the display 101 is refreshed. 

[0029] In addition to the event handling described above the event engine 1 1 7 may 
also act as a controller of the media engine 1 1 0c. The event engine 1 1 7 may control the 
times at which a graphical interface 120 is refreshed. This can be accomplished through 
the use of an event engine 1 17 timer, that fires an event at a certain frequency. When 
ever the event fires, the event engine 1 1 7 can access the template 1 1 3, and provide the 
template information to the Tenderer 1 1 1 along with the values of data elements 107 and 
information regarding the occurrence of events. The Tenderer 1 1 1 then uses this 
information to render a graphical interface 120 to the display 101. 

[0030] As described in the above paragraph, the media engine 1 1 0c or more 
particularly the event engine 117 stores the template information separately from the data 
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element and event information. It may be desirable to store all the information in the 
template 113. When a notification of a change to data elements 107 arrives via the 
content interaction APIs 1 12b, the event engine 1 17 may store this information in the 
template 113. In this manner the renderer 1 1 1 only needs reference to the template 1 1 3 
object to render the graphical interface 120. This can be achieved by in various ways. 
For example the event engine 1 1 7 may pass a copy of the template 1 1 3 information to the 
renderer 1 1 1 , it may pass a reference to the template 1 1 3 to the renderer 111. 
Alternatively the renderer 1 1 1 may be designed to access a template 1 1 3 located in a 
specific location. The event engine 1 1 7 would be responsible for ensuring that the proper 
template is located in the location. This method can be used advantageously as the media 
engine 1 10c may have numerous templates that the event engine 1 17 keeps updated with 
the application data element information and event information. The event engine 117 
can then be used to switch graphical interfaces 120 by updating the specific location with 
the desired template. 

[0031] The above description has described various calls that can be made to the 
content interaction APIs 1 12, 1 12b. Below is a listing of possible API calls that the 
media engine 1 1 0a, 1 1 0b, 1 1 0c should support. It must support at a minimum the update 
data call. Without this support the application cannot pass information to the media 
engine 110a, 110b, 110c to display. 

int update_data_element (string element_ID, string 
element_value) 

- used to notify the media engine to update the elementJD with the new 
element_value 

- returns an int for error purposes, may be other type or no return 

int notify_custom_event (string custom_event_ID) 

- used to notify the media engine of the occurrence of custom event ID 

- returns an int for error purposes, may be other type or no return 
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bool query jnew_event (string event_f ilter) 

- used to determine if a new event has occurred. The event_filter can be 
used to specify the type of events that are of interest. This call is normally 
implemented in media engines that use an event engine. 

- returns true if a new event has occurred that matches event_filter, false 
otherwise 

string get_new__event (string event_f ilter) 

- used to get a new event that matches event_filter. This call is normally 
implemented in media engines that use an event engine. 

- returns a string representing the event 

bool register_eventJListner (string application_ID, 
string listener_ID, string event_f ilter) 

- used to register an event listener with the media engine. applicationID 
is an identifier used to identify the application. The listener lD is used to 
determine the listener to register. This may be a function ID of the 
application. The eventjilter can be used to specify the type of events that 
are of interest. This call is normally implemented in media engines that use 
an event engine. 

- returns true if the listener_JD associated with the application ID could be 
registered to be notified of events that match event_filter 

[0032] The above calls and descriptions are just an example, those skilled in the are 
will recognize that more or fewer calls can be included, with different parameters and 
return values, while maintaining the functionality of the media engine 1 10a, 1 10b. 

[0033] Figure 3d shows in a functional schematic another example of a media engine 
1 1 Od, in accordance with an embodiment of the present disclosure. The media engine 
1 1 Od is similar to the media engines 1 1 0a, 1 1 0c previously described, however media 
engine 1 lOd also has a layout manager 1 1 8 similar to media engine 1 10b. The layout 
manager 1 1 8 may be used to handle the dynamic layout of data elements that are found in 
the template 113. 
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[0034] Data elements may be passed to the media engine as a string that can vary in 
length. The varying length of the string presents problems when laying out a graphical 
interface 1 20. If the string is too long, it may overlay other parts of the graphical 
interface 120. If the text is too short , other elements may not align properly. In the 
above examples of media engine 1 10a, 1 10c, although providing for flexibility of the 
specification of the graphical interface 120, no easy way of dynamically handling the size 
of data elements was described. Either the media engine must make some predetermined 
decision on how to handle the length of strings, such as truncating all strings that are too 
long. All though this works well, the layout manager 1 18 provides even greater 
flexibility to the media engines 1 10b, 1 lOd by providing a way of specifying how to 
handle the dynamic display of data elements. This allows a graphical interface designer 
to describe how data elements are to be handled by including layout manager 1 1 8 control 
information in the template file. As an example the template 1 13 and layout manager 118 
may be used to specify that a data element is to be 10 characters long, and that if the data 
element provided to the media engine is longer than 10 characters, that it should be 
truncated to 5 characters long, and the string . .)> appended to the end of the string. As 
another example, a graphical interface designer may wish to have the characters of a 
particular data element appear as all upper case characters. This can be specified in the 
template file. The layout manager would receive the data element string and modify it as 
determined by the template 1 13, in this case changing all of the characters to upper case. 
This manipulation of the data element is performed by the layout manager 118. The 
layout manager may be controlled by including, in the template 1 13 or the template file, 
directions to the layout manager 118 specifying how the length of a data element should 
be modified. The renderer 1 1 1 will then display the sting as prepared by the layout 
manager 1 1 8. The layout manager 118 allows for the text style of data elements to be 
specified and dynamically controlled. 

[0035] As shown schematically in Figure 3d, the layout manager may alter the data 
elements according to the dynamic layout described in the template and these changes 
may be stored directly in the template 113. The renderer 1 1 1 then uses the template 1 13 
in the same manner as previously described. Alternatively the data elements may be 
stored in the template 1 1 3 (or separate from the template 1 1 3) as provided from the 
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application 105. The layout manager 1 1 8 may alter the data elements as they are 
provided to the renderer 111. The layout manager may modify display characteristics of 
the element such as its placement, size, visibility, etc. In this manner the Tenderer 
receives the data elements as string describing the data element as provided by the 
application 105, and modified by the layout manager 1 1 8 in such a manner as described 
in the template 113. 

[0036] The layout manager may be used to control the display of elements other than 
text elements. A layout manager may be used to dynamically control the display 
characteristics of graphical information as well. A graphical interface designer may wish 
to display a graphic or image in a certain location only if there is no text that would be 
covered by its placement. The layout manager 1 8 can be used to provide a means of 
controlling the display of the element. For example if graphical interface 1 20 describes 
that an icon is to be displayed in a location free of text, the icon element can be passed to 
the layout manager 118, along with layout manager control information specifying the 
layout requirements. The layout manager may then dynamically alter the display 
information of the element in the template 1 13 prior to the element being rendered. The 
layout manager 1 1 8 may alter the coordinates specifying the placement of the icon, or it 
may determine that there is no space available on the graphical interface 120, and so the 
icon should not be displayed. The modified element with the dynamic display 
characteristics can then be passed to the renderer 1 1 1 for rendering to the graphical 
interface 120. 

[0037] The layout manager 1 1 8 can provide a means of manipulating data elements 
prior being rendered by the renderer 1 1 1 , as well as providing a means of dynamically 
controlling the display characteristic of elements that the renderer 1 1 1 may not be able to 
render appropriately. The template 1 13 can specify information for controlling the layout 
manager 118. 

Figure 4 shows in a pseudo code listing an example application 400. The example 
application 400 is contrived to describe the functioning of the system and methods of the 
present disclosure. The example application 400 defines two data elements. The first 
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405 is an integer named 'datajnt', the second 407 is a string named 'data_str\ The 
example application 400 adds one to the value of datajnt, which is initially zero, each 
time it receives a 'scroll_wheel' user input. The example application 400 may receive 
this information from the operating system 103. Additionally or alternatively, the 
application may be designed to make use of the event engine's 1 17 user input 
functionality previously described. When the value of datajnt is equal to five, the 
example application 400 changes the value of data_str to 'Big Int' and creates a custom 
event named 'big_int_event\ When the value of datajnt is equal to 10, the value is 
reset to zero, the value of data_str is changed to 'Small Int* and a custom event named 
' small Jnt_evenf is created. 

[0038] The example application 400 notifies the media engine 1 1 0a, 1 1 0b, 1 1 0c, 
1 lOd of any changes to the value of a data element 405, 407 using the media engine API 
call named l update_data_element\ The update_date_element expects a string identifying 
the ID of a data element. This is chosen to be the same as the name of the application 
data_element. This is not a requirement of the system, but rather is an easy way to ensure 
consistency when updating data elements. The string for data_element JD representing 
an element in an array of data elements may be constructed by appending the array name 
with the index number of the particular element. The updatedataelements also expects 
a value representing the updated value of the data element 405, 407. An example 
definition of the API used for notifying the media engine of updates to data elements is: 

Int update_data_element (string data_element_ID, string 
value) 

[0039] The updatedataelement defined above returns an integer that may be used 
for error detection. It may be used to detect various conditions, such as if the data 
element 107 could not be located, or if the value could not be changed, or if the value was 
updated properly, etc. The call expects a string representing the ID of a data element 
107. This ID is the string that the template file uses to describe how to display the data 
element 1 07. It could alternatively be another type, such as an integer, as long as the 
template file used the same type for identifying the data elements 107. The value of the 
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data element 107 is defined as a string, again this could be changed to another type, as 
long as the template file described how to display the type. 

[0040] The example application 400 notifies the media engine 1 10a of the occurrence 
of any custom events using a media engine API call named 'notify_custom_event\ The 
notify_custom_event call expects a string identifying the ID of a custom event. The 
string could be replaced by an integer or other type, as long as the template file uses the 
same type for identifying the events. An example of the API used for notifying the media 
engine of the occurrence of events is: 

Int notify_custom_event (string event_ID,) 

[0041] The notify_custom_element defined above returns an integer that may be used 
for error detection. The call expects a string representing the ID of a custom event. This 
ID is the string that the template file uses to identify the event. It could alternatively be 
another type, such as an integer, as long as the template file used the same type for 
identifying the event. 

[0042] The example application 400 of Figure 4 does not include any code that 
controls how or when the information is displayed. It contains code to control user input, 
notify the media engine 1 10a, 1 10b, 1 10c, 1 lOd of updates to date elements 405, 407 and 
of the occurrence of events. The media engine 1 10a, 1 10b, 1 10c, 1 lOd uses the template 
1 13 to determine how to render the information to the display. 

[0043] A template file for specifying a graphical interface 1 20 to the example 
program can be created using a markup language. Below is an example of a possible 
template file that describes how to display the example application 400 information. 

Example GUI 1 : 

<text id ="data_int" x="5" y="5" f ont-f amily="myf ont" 
font-size="15" f ill="black">not set</text> 

<set xlink:href="data_int" attributeName="f ill" 
to="green" begin=" custom (Big_Int) " 
end="custom(Small_Int) "/> 
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<set xlink:href=»data_int" attributeName=»f ill" 
to="red" begin="custom(Small_int) " 
end=" custom (Big_lnt ) "/> 



[0044] The above shows an exert from a template file that could be used with the 
example application. It defines a <text> element with an ID of 'data_int\ This is the 
same ID that the application sends to the media engine 1 10a, 1 10b, 1 10c, 1 lOd. The 
<text> element specifies how to format and position the text on the display 101 . The 
exert also defines two <set> elements. These elements are used to change the way the 
renderer 1 1 1 renders the information based on application events. When a 'Bigjnt' 
custom event arrives at the media engine 1 10a, 1 10b, 110c, HOd from the example 
application 400, the fill colour of the data_int element is changed to green. The set 
element also defines when to stop using the associated <set> characteristics, in the above 
case this is when the custom event 'Smalljnt' is received at the media engine 1 10a, 
1 10b : 1 10c, 1 lOd. The second set element describes the display properties of data_int 
when the custom event 'Smalljnt' is received. It describes setting the elements fill 
colour to red. 

[0045} The above template only describes displaying one data element 405 for the 
example application 400 that defines two data elements 405, 407. The application data 
element data_str is not displayed. The media engine 1 10a, 1 10b, 1 10c, 1 lOd can discard 
or disregard any updates of this data element 407 it receives from the example application 
400. 

10046] Another possible template file describing a different graphical interface 120 
for the same example application is: 

Example GUI 2: 

<text id =''data_int» x="5» y="5" f ont-family="myf one" 
font-si Z e=»15'' fill=»black">not set</text> 

<text id =''data_str» x="5» y=»25" font-f amily=»myf ont2» 
font-size=»10'' f ill =» grey" >not set</text> 
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[0047] The above example graphical interface 120 describes the position of both data 
elements 405, 407 of the example application 400. This interface does not make use of 
the custom events sent from the example application 400. The media engine may discard 
or disregard the notification of custom events from the example application 400. 

[0048] Figure 5a shows in a flow chart 500 a method for creating a graphical 
interface 120 associated with an application 105 according to the present disclosure. An 
application 105 starts on the device an notifies the media engine 1 10a, 1 10b, 1 10c, 1 lOd 
of its ID. The media engine 1 10a uses this ID to locate a template file in the template 
library (501 ). Other methods of associating a template file with an application will be 
apparent to one skilled in the art. If the media engine 1 10a, 1 10b, 1 10c, 1 lOd determines 
that no template file was found (510), an error is formed (512). This error may be 
reported back to the application 105. 

[0049] The media engine 1 1 0a, 1 1 0b, 1 1 0c, 1 1 Od may also present an error on the 
screen. One option to do this is shown. The application 105 exits in response to the error 
(513). The media engine 1 1 0a, 1 1 0b, 1 1 0c, 1 1 Od loads and parses an error template from 
the library (514). This error template file may be a standard graphical interface 
describing only static objects, that is no application data elements 107 or application 
custom events. The template 1 13 is passed to the renderer 1 1 1 (540) which then renders 
the template 1 13 to the display 101. The media engine determines that the application 
has exited (545) and ends the processing at step 550. 

[0050] If the template file is found it is passed to the parser 1 14 (51 5) which parses 
the template file and stores the template information in a template 113 (520). The media 
engine 1 10a then waits to receive updates to data elements 107 or notification of custom 
events (525). When a data element 107 update or custom event notification arrives, the 
ID is checked (527). If the data element or event ID is found in the template 1 13, the 
processing continues to step 530. If the ID is not found in the template 1 1 3, then 
processing returns to step 525, effectively discarding the update or notification. The 
updated information or notification information is used to update the template 113 (530). 
In this case the media engine 1 10a, 1 10b, 1 10c, 1 lOd stores the information in the 



- 17- 



WO 2007/131359 



PCT/CA2007/000864 



template 113. It may be desirable to store the data element 107 and event information 
apart from the template 1 1 3 . In this case instead of updating the template 1 1 3 the media 
engine 1 10a, 1 10b, 1 10c, 1 lOd would store the information. If the media engine 1 10a, 
1 10b ? 1 10c, 1 lOd stores all the information received from an application 105 the step of 
checking the template for the IDs (527) may be skipped. Alternatively the IDs may not 
need to be checked if the media engine only receives data elements or events for IDs used 
by the template 113. This may be used to allow the switching of graphical interfaces 1 20 
without requiring the application 105 to communicate all of the information again. The 
media engine 1 1 0a, 11 Ob, 1 10c, 1 1 Od determines if the graphical interface 1 20 should be 
updated (535). If it is not to be updated processing returns to step 525. If it is to be 
updated the template 1 13 is passed to the renderer (540). As previously disclosed, other 
options exist for passing the display information to the renderer 111. After the 
information is passed to the renderer 1 1 1 the media engine 1 10a, 1 10b, 1 10c, 1 lOd 
determines if the application has exited (545) if it has not, processing returns to step 525. 
If the application has exited then the processing ends (550). 

[0051] Figure 5b shows in a flow 560 chart another method for creating a graphical 
interface 120 associated with an application 105 according to the present disclosure. The 
parser 1 14 parses template information (565) from a template file and stores it in a 
template 113 (570). Updated data element information is received from an application 
1 05 through the use of the content interaction API (575). The template 1 13 is updated 
with the received update data element information (580). The layout of the data element 
information is controlled using a layout manager 1 1 8 (585). This may include truncating 
a data element string, appending other characters to the data elements, changing the 
display characteristics of the elements or other modifications. The template 1 13 is 
passed to the renderer 1 1 1 (590) and the renderer renders the graphical interface 120 
(595). 

[0052] A skinning system comprises a media engine 1 10a, 1 10b, 1 10c, 1 lOd for 
rendering an SVG document 1 1 5 on a device 1 00. The media engine 1 1 0a, 1 1 0b, 1 1 0c, 
1 lOd includes a skinning API (or a content interaction API)1 12. The skinning system 
also includes an SVG language document 1 1 5 and an SVG transcoder or parser 1 14. A 
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content developer uses the SVG language and the SVG transcoder to create a skinning 
document as the template file. An application developer uses the media engine 1 10a, 
1 1 Ob, 1 1 0c, 1 1 Od and skinning API 1 1 2. A device application 1 05, such as a home 
screen application, uses the media engine 1 1 0a and skinning API 1 12 for its skin or 
graphical interface 120. 

[0053] Examples of components of a skinning system in an embodiment of the 
present disclosure are now described. A skin for a home screen application is described 
in order to describe the structure of the template file. The examples used to illustrate the 
format of the template document, along with the functionality of the media engine. 

Integration of application and system data into the Home Screen skin 

[0054] A Today style home screen consolidates application and system information 
and into a single view. This information will be organized according to the theme 
designer's layout specified in a home screen SVG file. 

Today Home Screen Elements 

[0055] Figure 6 shows in a screenshot an example of a Today style home screen 
view, in accordance with an embodiment of the present disclosure. 

User configuration of Home Screen 

[0056] The set of applications (and associated data) is determined by the elements of 
an SVG file that is incorporated into the theme. Preferably, user configuration of the 
fixed set of applications that are represented on the Today style home screen include the 
following 

• The representation of item 26 in Figure 6 is user configurable from 
Message Status Options. I.e., whether unread, new or nothing is 
displayed. 
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• The representation of items 13, 15, 19 and 22 in Figure 6 are 
dependant on the date representation of the current locale and the 
user's selection of Time Format. 

Integrating application data into SVG 

[0057] The home screen supports the ability to incorporate special "data elements" 
into the skin file. A data element is a place holder in the skin for user data or system 
information. This will allow the skin designer to specify a template of the home screen 
while allowing application to fill in the contents with the appropriate information. Data 
elements for specific applications are defined within each sub feature. The skin designer 
can control the appearance and behavior of the data elements through any supported SVG 
syntax. The set of data elements that the home screen designer can incorporate into the 
skin is collectively referred to as the "data palette". Example data elements include: 

<g id= n hsl n font-family="BBMillbank" font-size="10"> 

<text id=" email 1 time" x="30" y="200 n x/text> 

<text id=" email lFrom" x="50" y=»200" font- 
style="Bold"></text> 

<text id="emaillSubject" x=»100" y="200"></text> 

<set xlink:href="caret" attributeName="y" 
begin= " focus in n to= 11 200 11 f ill= " freeze " /> 

<loadScene begin= "activate" xlink:href ="x- 
exec : //LaunchInternal?id=emaill"/> 

</g> 



[0058] emaillTime, emaiilFrom, emaillSubject are examples of data elements that 
are populated with application (in this case messages) specific information by the home 
screen application. Data elements for each application are described within their 
respective subsection of this document. 
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Navigation 

[0059] The home screen SVG layout will allow the creation of user selectable 
hotspots. For example, the skin designer may create a hotspot that highlights the row 
containing the last new received email (labels 27, 28, 29 Figure 6). The user may focus 
on this hotspot by rolling the trackwheel. The SVG syntax allows the home screen 
designer to specify an action associated with focus in, focus out and activate (I.e., 
clicking the thumbwheel). The navigation order is the order that the hotspots are defined 
in the SVG. An example of an SVG hotspot includes: 

< image id=" caret' 7 x="30" y= n 180" width="200 n 

height = "30" xl ink : href = ■ caretBar . png ■ < / image> 

<g id=»hsl» font-family="BBMillbank" f ont-size="l0"> 

<text id="emailltime" x=»30" y= n 200 l1 ></text> 

<text id=" email ISender" x= !, 50" y=»200" font- 
style=:"Bold"></text> 

<text id="emaillSubject" x="100" y="200 H </text> 

<set xlink: href = /r caret" attributeName="y" 
begin=»focusin» to="200" f ill="f reeze"/> 

<loadScene begin=» activate" xlinkihref ="x- 
exec : / /Launchlnternal?emaill " /> 

</g> 



10060] In the above example a hotspot is provided that has a focusin and activate 
action. The focusin <set> translates the caret image to the correct location. The 
<loadScene> element will open the message that corresponds to the email 1 data element. 

Dynamic Layout 

[0061] Layout presents a challenge when implementing a home screen that 
incorporates text that can have varying length. Examples of such strings include email 
subject/sender, calendar subject/location, etc. A layout manager is used to handle the 
dynamic length of the data elements that are populating the home screen template. 
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[0062] Unfortunately, SVG does not provide this ability natively. An extension to 
the language is provided that allows the specification of how data elements are laid out 
with respect to each other. In the Today style view, the requirements call for a column- 
wise layout of data elements. For example, the requirements for calendar integration 
state 

• "Subject. If the subject is too large to fit the available space it will be 
terminated with 

• Location. If the location is too large to fit the available space it will be 
terminated with 

[0063] Preferably, each element has independently themed text styles. The time and 
subject fields will be left aligned into a column. The subject field will be given a 
maximum width and the location field will immediately follow the subject field. 

[0064] The above involves the home screen providing a column-wise layout manager 
where each column specifies an available/maximum space and a rule for truncating the 
string if it is too long to fit within that space. If a field has a display attribute that is set to 
"none" it will not occupy any space for the purposes of laying out subsequent text 
elements. The home screen skin has the ability to specify a layout manager that controls 
the position of data elements within the skin. For example, a <foreignObject> element 
may specify a layout rule and references elements within the skin file. For example: 
<foreignObject> 

<image x=»81» y=»216» width="230" height= "20 » 
xlink:href ="x- 

object:/layout?ids=calendar2subject;calendar2locatio 

n&width=230&amp ; spacing=5&ellipsis=… " 
/> 

</foreignObject/> 
[0065] Another possibility is to use compound documents html tables + svg. 
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Default Application Representation 

[0066] The home screen provides the ability to refer to application descriptions 
within the home screen SVG file using the <image> element or <text> element. These 
are different ways to specify an application name. The <text> method is generally better 
because it can leverage the SVG syntax and features. The <image> method is legacy. 
The application is identified by specifying it's module name and entry point as the value 
of the "id" parameter of the xlink:href attribute. An application description is referenced 
by prefixing the xlinkrhref attribute with the string "x-object:/EntryDescription". The 
application description will be retrieved from the ApplicationEntry class. An example of 
an application description for Phone application includes: 

<image x=»32" y="65" width="276" height="24" 
xlinkrhref ="x-bject : /EntryDescription?f ont- 
family=BBClarity& f ont-size=15& font- 
s tyle=bold&amp ; id=net_rim_bb_phone_app . Phone&amp ; ali 
gn=lef t &amp ; width=2 76&amp ; height=24&amp ; enclosing= ( ) 
& shovmame& showinf o" > 

<set attributeName= "visibility" 
begin="hsl.focusin" to="visible" f ill="f reeze" /> 

<set attributeName=" visibility" 
begin="hsl.focusout" to="hidden" f ill="f reeze"/> 

</ image > 

[0067] An alternate representation using a <text> "data element" for the application 
description called "calendar_app" is: 

<text id="calendar_app" x="32" y="180" style="font- 
f amily : BBCondensed ; font - si ze : 12 ; font -weight : bold ; 
fill:#394142"> 

<set attributeName= n f ill" to="#FPFFFF» 
begin= "hs5 . f ocusin" end="hs5 . f ocusout "/> 

</text> 
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[0068] The above example specifies an image that is the focused state of messages 
application description. Note that the <set> animations will toggle the visibility attribute 
of the <image> element when it receives and looses focus. 

[0069] Below is an example of a summary table of the xlink:href url parameters for 
EntryDescription. This summary table applies to the <image> method for specifying 
application descriptions. The <text> element supports all the attributes of SVG. The 
<image> mechanism supports an overlapping set but there can be some attributes that are 
supported by <image> that are not supported by <text> (I.e., showlnfo) in one 
implementation. 



Name 


Type 


Value 


Default 


font-fa milv 

ivi ll 1 CI 1 1 Illy 


f^r\t ir\r*ol 

upuuriai 


ront name 


System default 


font-style 


Optional 


PLAIN,BOLD,ITALIC 


PLAIN 


font-size 


Required 


Integer 


none 


Foreground-color 


Optional 


Integer in HEX 


0 = BLACK 


Id 


Required 


Application Entry 
name 


none 


Align 


Optional 


Left f center,right 


left 


Width 


Required 


Integer. 


none 


Height 


Required 


Integer 


none 


Enclosing 


Optional 


0 or 0 org 


blanks = no enclosing 


Showinfo 


Optional 


boolean 


if present, the Application 
Name is displayed 


Shown a me 


Optional 


boolean 


if present, the unread 
count (or new count) is 
displayed 
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Application Icons 

[0070] The home screen provides the ability to refer to application icons within the 
home screen SVG file using the <image> element. An application icon is referenced by 
prefixing the xlink:href attribute with the string "x-object:/EntryIcon". The application is 
identified by specifying it's module name and entry point as the value of the "id" 
parameter of the xlink:href attribute. The icon will be retrieved from the 
RibbonlconField class in one implementation SVG can refer to an application icon that 
is provided by the skin (hard coded) or can refer to an icon that is provided by the 
application it's self. The x-object:/EntryIcon xlink:href attribute provides the mechanism 
for referring to an application icon that is provided by the application. The non x-object 
mechanism refers to an image file directly, i.e., xlink:href="messageIcon.png". 

Focused representation 

[0071] Application icons may have a focused and unfocused representation. This is 
specified by the presence of the "focus" parameter of the xlinkrhref attribute. For 
example: 

< image x="-4" y=»206» width="48" height ="3 6" 
xlink : href = "x- 

object : /Entrylcon? focus& id=net . rim. Prof ileHomeSc 
reenApp&amp ; size=36&amp ; width=48&amp ; height =3 6 " /> 

[0072] An Entrylcon which does not include to "focus" parameter will be rendered in 
the unfocused state. For example: 

<image x="-4 n y=»206" width= n 48 n height="36" 
xlinkrhref = "x- 

ob j ect : /Entrylcon? id=net . rim . Prof ileHomeScreenApp&am 
p ; si ze=3 6 &amp ; width=4 8&amp ; height = 3 6 11 / > 

[0073] Preferably, it is the responsibility of the SVG to define animations (I.e., using 
<animate> or <set> elements) which toggle the visibility of the focused and unfocused 
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icon representations. Visibility, opacity and x,y location are attributes of this kind of 
foreign object element that are animatable through SVG. 

[0074] Every application will have a minimum, default visual representation that is 
used for that application. In addition to this representation, some applications will define 
alternative representations for use in specific situations such as the home screen, or in 
banners for example. For Messages, at a minimum, it provides an icon and a name. This 
default representation is used in icon themes using the icon grid layout and in an 
applications list (such as the BlackBerry Applications List). In one theme, Messages can 
be represented on the home screen along with a count. In the banner it provides a smaller 
envelope and a count, but no name. In another theme's skin, it can provide a list of the 
most recent new emails. These additional representations are defined above and beyond 
the minimum, default representation of an icon and a name. Elements of the default 
representation can be defined by the theme, or as resources within the application itself. 
An example of elements of the default representation are as follows: 

• Name : The themed name overrides the name provided by the 
application. 

• Icon (optional) : The themed icon overrides the icon provided by the 
application. If neither icon is available, the default application icon 
provided by the theme is used. 

• Icon - in-focus (optional) : This icon is used when the icon is in focus. 
If no icon is available, the normal icon is used. 

• Icon - disabled (optional) : This icon is used when the application is 
visible, but disabled. For example, when there are no browser service 
books, the default browser is disabled. If no icon is available, the 
normal icon is used. 

Unread Count Representations 

[0075] There are different ways of specifying an unread count in the home screen 
SVG syntax. In one method (Method 1) a foreignOject mechanism is used: 
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< image x="99" y="4 0" widths" 35 11 height=" 13 ,r 

xlinkrhref ="x-object : /UnreadCount?type=email 
&amp ; align=lef t&amp ; width=35&amp ; height=13 " /> 

[0076] Method 1 allows the home screen to embed an unread count for email. 
Associating an application entry with an unread count would prohibit the unread count 
from being associated with an EntryDescription or Entrylcon (which is an open slot), 
method 1 from being used in a slot type home screen design. A slot design refers to the 
ability to specify application placeholders that are dynamically populated based on the 
order of applications in an applications list (such as the Blackberry Applications List). 

[0077] In another foreign object method (Method 2) of including the unread count 
with the application name: 

<image x="32" y=»65" width="276" height="24" 
xlink:href ="x-object : /EntryDescription? f ont- 
family=BBClarity& font-size=15& f ont- 
style=bold&amp ; id=net_rim_bb_phone_app . Phone&amp ; ali 
gn=lef t&width=276&height=24&enclosing= () 
&amp ; showname& showinf o " ></image> 

[0078] Method 2 can optionally specify a "showinfo" parameter which will render 
extra info if such info is provided by the application (see 3.12.1.6). The extra info that an 
application provides is not under control of the theme or SVG skin. This extra info is 
typically an unread or new count. If the "showinfo" parameter is specified the info will 
be displayed immediately to the right of the description. 

[0079] For example: Messages (1): If the unread count is 0 the count and braces will 
not be displayed. In some circumstances the fact that the unread count is displayed next 
to the name may be configurable by the user via some option. For example the 
configuration of feature 3.10 (new message status options) will determine whether or not 
the count is displayed as well as it's meaning (I.e., new vs. unread). 

[0080] Another possible approach to integrating unread counts into the skin through 
the use of <text> and <tspan> elements with known IDs, i.e., data elements. This may 
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be a superior approach because it will give more control to the home screen skin over 
how the unread counts are rendered. It would also allow the counts to be animated. For 
example: 

<text id="messagesName" font-name="BBCasual" font- 
size="10" font -style= "bold" > 

<tspan font-style="plain , '> [</tspan> 

<tspan id="messagesInfo" f ont-style="plain"></tspan> 

<tspan font-style="plain">] </tspan> 

</text> 

[0081] This is a Non foreign object way of specifying application names and unread 
count using only data elements (I.e., id="messagesName" and id="messagesInfo") and 
leverages the syntax and features of SVG. In the above example the ids 
"messagesName" and "messageslnfo" would be recognized by the home screen 
application and the appropriate info would be substituted into the skin. 

User Configurable Application Slots 

[0082] The home screen skin may reference an application in the applications list 
(i.e., Blackberry Applications List) by specifying its numerical order in the list starting at 
0 which is the first element in the list. For example: 

<image x= ,, 280" y= n 104 n width= n 39" height= ,l 29" 
xlinkzhref ="x- 

ob j ect : /Entrylcon? id=slot O&amp ; size=29&amp ; width=3 9& 
amp ; height =2 9 " > 

</ image > 

[0083] In this case, id=slot0 specifies that the skin is referencing the first application 
in the applications list. 

[0084] The home screen will allow the skin designer to integrate items from the 
applications list into the home screen layout. The skin designer will be able to specify 
the location of the menu item slots and their position within the navigation order of the 
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screen. The applications that occupy these slots will be configurable by the user. For 
applications that extend the default representation, the default extensions will also be 
shown. 

Calendar Integration into Home Screen skin 

[0085] This feature provides the ability to integrate calendar information into a home 
screen SVG skin. Figures 7a, 7b and 7c illustrate in screenshots examples of calendar 
integration into a home screen skin, in accordance with an embodiment of the present 
disclosure. 

Calendar Event Order 

[0086] The data elements for calendar will reference calendar events according to 
their ordinal position in a list sorted by the following criteria: 

1 : Start time (earliest to latest). 

2: Creation time (earliest to latest). 

[0087] In addition, the list will be filtered according to the following criteria: 
1 : Exclude calendar events which have finished. 

[0088] The skin is updated whenever the list is modified. The list is updated when 
any of the following actions occur: 

• Device Date/Time is modified by the user. 

• Device time zone changes. 

• Device boots. 

• An event is replaced by another calendar event. 

• An event is deleted. 

• An event is updated. 

• An event ends. 
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♦ Data Element Table 

[0089] The following table describes the data elements related to calendar which may 
be incorporated into the home screen SVG skin. Descriptions of the columns are as 
follows: 



Element name: The name of the "id" attribute. This identifies the element to the 
home screen skin. These names are case sensitive and must be 
specified exactly as shown in the table. 

Elements description: A description of the application data that will populate the 

element. 



Element type: The SVG element type of the data element. The data element must 

be of the specified type. 



Element 
name 


Element description 


Element 
type 


calendar<n> 
time 


The time/date of the nth calendar event in the list of 
calendar events. 

The time is formatted according to the "Time 
Format" setting in the Date/Time options screen. If 
the event occurs in the current calendar day (in the 
local time zone) only the time is shown. If the event 
occurs in a future calendar day (in the current time 
zone) only the date is shown. 
The date will be formatted with 
net.rim.device.api.i1 8n.SimpleDateFormat in 
accordance with the DATE_FORMAT_STRING key 
in Ribbon.rrh. 


<text> 
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subject 


i ne suDject line ot the nth calendar event in the list 
of calendar events. The text will be truncated with 
an ellipsis if it is too long to fit within the available 
space given by the layout manager. 


<text> 


calendar<n> 
location 


The location of thp nth calendar o\/e»nf in tho lief 

• i ivvauui i \ji u Mill IsaldlUdl cvtflll III 1116 IISl. 

The text is truncated with an ellipsis if it is too long to 
fit within the available space given by the layout 
manager. 


<text> 



Application Entry Points 

[0090] The home screen SVG syntax will provide the ability to launch the nth 
calendar item in the Calendar Event through the <loadScene> element. For example: 

<loadScene begin= "activate" xlinkihref = "x- 
exec : //LaunchInternal?calendarl/> 



[0091] The above example opens the first calendar event in the calendar event list. 
The home screen SVG syntax provides the ability to launch the calendar application 
through the <loadScene> element For example: 

<loadScene begin= "activate" xlink: href = "x- 
exec : //net_rimjDb_calendar_app . Calendar/> 

[0092] The above example launches the calendar application. The default view will 
be displayed. 

Custom Events 

[0093] The home screen skin has the ability trigger animations on custom events 
related to the data elements described in the data palette. This may be used to trigger 
animation effects when information/status is updated. Below is a table that describes an 
example of custom events for calendar: 
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Event name 


Event Description 


Calendar<n>begin 


The nth calendar event has begun. 


Calendar<n>endpre 


The nth calendar event is ending. This event is fired prior to 
the data elements in the skin being updated as a result of the 
nth calendar event ending. The skin has an opportunity to 
trigger a custom animation such as a transition out effect (For 
example a fade out or animation off the screen). If the skin 
does not define an animation on calendar<n>endpre then 
calendar<n>endpost (see below) is fired immediately. If the 
skin defines an animation on calendar<n>endpre it waits until 
all animations beginning on this event have completed before 
firing calendar<n>endpost. Preferably, animations are not 
aeiinea inai nave our= maeiinite otnerwise 
calendar<n>endpost will never be fired. 


calendar<n>endpost 


The nth calendar event has begun. This event is fired after 
all of the data elements related to calendar (see data element 
table) have been updated. 



[0094] The following SVG illustrates how to achieve a fade out and fade in effect 
before and after the data is updated for the calendarl event: 



<g id=»hsl» font-family="BBMillbank" f ont-size=" 10"> 

<text id=" calendarl time" x= n 30" y= ,, 200"x/text> 

<text id=" calendar lSubject" x="50" y="200" font- 
style="Bold" ></text> 

<text id=" calendar lLocat ion" x= n 100" y="200" 
</text> 

<animate attibuteName=" fill -opacity" to="0" 
dur="2s" begin="calendarlEndPre" fill=" freeze" /> 

<animate attributeName=" fill -opacity" to="l" 
dur="2s" begin="calendarlEndPost" fill=" freeze" /> 

</g> 
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, 10095] Preferably, there is also a mechanism of getting the skin into the correct state 
if the device was off for some reason when the event was supposed to happen. 

[0096] Calendar status will include the ability to represent 1 -n of upcoming calendar 
events for the current day. Clicking on these events will open them or bring up a context 
sensitive menu if requirement 10 is supported. These events will include: 

• If the event is scheduled today, the time will be shown using the 
localized time format. 

• If the event is scheduled beyond today, the date will be shown using a 
localized MM/DD format. 

• Subject. If the subject is too large to fit the available space it will be 
terminated with"..." 

• Location. If the location is too large to fit the available space it will be 
terminated with „" 

[0097] Each element will have independently themed text styles. The time and 
subject fields will be left aligned into a column. The subject field will be given a 
maximum width and the location field will immediately follow the subject field. 

[0098] Preferably, calendar events will be removed from the list when the meeting 
ends. The exception will be all day events, which will be removed 1 hour before the start 
of the meeting that will bump it off the list. 

Phone Integration into the Home Screen skin 

[0099] Figures 8a and 8b show in screenshots examples of phone integration into the 
home screen skin, in accordance with an embodiment of the present disclosure. 
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Element name 


Data description 


Home Screen 
skin SVG 
element type 


missedcalls<n>time 


The time of the nth last missed call. 
The time is formatted according to the 
"Time Format" setting in the Date/Time 
options screen. If the event occurs in the 
current calendar day (in the local time 
zone) only the time is shown. If the event 
occurs in a past calendar day (in the 
current time zone) only the date is shown. 
Preferably, the date is formatted with 
net.rim.device.apU1 8n.SimpleDateFormat 
in accordance with the 
DATE_FORMAT_STRING key in 
Ribbon.rrh. 


<text> 


missedcalls<n>info 


The info of the nth missed call. For 
example (name or phone number or 
unknown number). If an address entry 
exists for the phone number it shows the 
caller's name. If the name is too long to 
fit the available space defined by the 
layout manager, it is terminated with 


<text> 



Alternate Application Representation 

[00100] The home screen SVG supports the integration of an icon and text 
representation for an application. This is accomplished by specifying an Entrylcon and 
EntryDescription <image>. The Entrylcon and EntryDescription for phone will display 
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alternate representations depending on whether or not there are new missed calls. If there 
are new missed calls the EntryDescription will display "Missed Calls" whereas if there 
are no new missed calls it will display "Phone." The Entrylcon will display a different 
icon depending on whether there are missed calls or not. 

Application Entry Points 

[00101J The home screen SVG syntax also provide the ability to launch the phone 
application directly through the <loadScene> element. For example: 

<loadScene begin=" activate" xlinkihref ="x- 
exec : //net_rim_bb_phone_app . Phone /> 

[00102] This is related to requirement a) noted above, i.e., that the application should 
be able to react to user input from the GUI. This ability allows an application to register 
for events that are generated by clicking on an SVG element. The application registers 
itself with the Media Engine API as a MediaListener. When an event is generated by the 
<loadScene> element a notification is made to the registered MediaListener 
implementation. The implementation receives a notification that includes the xlinkihref 
URI which the code can use to determine which element was clicked and take appropriate 
action. 

[00103] Another example of a mechanism for SVG to register for notifications does 
not use the <loadScene> element. The application listens for activate events on the 
element directly rather than <loadScene> elements which are triggered off of activate 
events. As long as the element is focusable the activate event will be generated. A 
focusable element is one that has an infocus, outfocus or activate <animate> defined for 
the element. For example: 

< image id=" my Image 11 x="110" y="i9" width="20" 
height = "18" xl ink : hre f = n my Image . png " > 

<!-- dummy <set>: begin conditions of this node allow 
external listeners to listen to the activate events. 
(If there was nothing in the SVG dependant on the 
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activate events, they wouldn't get processed or 
fired to the external listeners) --> 

<set attributeName= "visibility" 
to= "visible" begin= "mylmage . activate " /> 

</image> 

[00104] Specifying a Launch Phone action that is tied to an arbitrary key event: The 
home screen will provide the ability to define an entry point which is tied to an access 
key For example: 

<loadScene begin="foo.accessKey ( "send ")" 

xlink : href = "x- exec : //net_rim_bb_phone_app . Phone /> 

[00105] In the example "foo" is the name of the element which must be in focus in 
order to trigger the loadScene event. accessKey("send") is the key event upon which to 
trigger or begin the action. The example essentially says "launch the phone application 
when the element named "foo" is in focus and the send key is pressed." 

[00106] Specifying a Launch Phone action with an optional dial number parameter: 
The phone application entry point will be able to accept a parameter which is a command 
to dial followed by the number to dial. For example: 

<loadScene begin="foo.accessKey ("send ")" xlink : href ="x- 
exec : //net_rim_bb _j?hone_app . Phone?command=dial : <miss 
edcallsl>/> 

<loadScene begin="f oo.accessKey ( "send" ) " xlink : href ="x- 
exec : //dialselected" /> 

[00107] In the example command=dial:<number> is the action that is passed to the 
phone application when the loadScene action begins. The home screen application 
should substitute the appropriate number into <missedcallsl> before passing to the phone 
application since the term "missedcallsl" is a home screen construct unknown to the 
phone application. The example says "launch phone application and dial the number 
matching <missedcallsl> when the element named "foo" is in focus and the send key 
event is pressed 
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[00108] Specifying a Launch Call Log Entry Context Menu action: The home screen 
SVG syntax will provide the ability to launch a popup menu for a call log entry 
corresponding to a missed call data element. This behavior can be specified through the 
<loadScene> element in the home screen SVG file. For example: 

<loadScene begin= "activate" xlinkrhref ="x- 
exec : //Launchlnternal?missedcallsl / > 

SMS and MMS Integration into the Home Screen 

[00109] Figure 9 shows in a screen shot an example of SMS and MMS integration into 
the home screen, in accordance with an embodiment of the present disclosure. 



Data Element Table 



Element name 


Element description 


Element type 


sms<n>time 


The time of the nth last new sms or mms 
message. The time is formatted according to 
the 'Time Format" setting in the Date/Time 
options screen. If the message was received 
in the current calendar day (in the local time 
zone) only the time is shown. If the email 
was received in a past calendar day (in the 
current time zone) only the date is shown. 
The date will be formatted with 
net.rim.device.apU18n.SimpleDateFormat in 
accordance with the 

DATE_FORMAT_STRING key in Ribbon.rrh. 
If "Display Time" is set to no in Messages 
Options -> General Options, this field is not 
displayed. I.e., its "display" attribute is set to 
"none". 


<text> 
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sms<n>from 


The sender of the nth last new sms or mms 
message. If an address book entry exists for 
the email address, the contact name is 
shown instead. If the contact name or email 
address is too large to fit in the available 
space it is truncated with 
If "Display Name" is set to no in Messages 
Options -> General Options, this field will not 
be displayed. I.e., its "display" attribute is set 

tn "nfjnp" 

l\J I ISJI ic . 


<text> 


sms<n>body 


The body of the nth last new email. If the 
body is too large to fit in the available space 
it is truncated with If the body is empty 
nothing is displayed. 


<text> 



Application Entry Points 

[00110] The home screen SVG syntax will provide the ability to define a <loadScene> 
element which opens a message associated with a data element. SVG syntax for opening 
a message: 

<loadScene begin== "activate" xlinkihref = "x- 
exec : //LaunchInternal?smsl/> 

[00111] The above example opens the sms or mms message associated with smsl from 
the data element table. 

[001 12] The home screen SVG syntax provides the ability to define a <loadScene> 
element which opens the combined sms and mms inbox. It will do this by specifying the 
module name and entry point name. SVG syntax for opening the messages application: 
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<loadScene begin=" activate" xlinkrhref ="x-exec : // 
net_rim_bb_messaging_app . sms_and_mms " /> 

New/Unread Message Count 

[00113] The count associated with the combined SMS and MMS entry point is 
configurable via the message status options screen. The text style and enclosing braces is 
configurable in the home screen SVG. 

Home Screen Area of Organize Applications 

[00114] The Home Screen SVG skin file may specify "slots" for applications as 
described. A (themeable) area is rendered at the top of Organize Applications screen 
that indicates how many slots are available and which applications occupy them. This 
area has a title called "Home Screen". The size of the area depends on the number of 
slots available in the home screen skin. The user may move applications in and out of 
this area through the normal move operation in Organize Applications. Slots which are 
assigned to fixed applications in the home screen skin do not appear in the list. 
Preferably, care is taken by the theme developer not to prioritize applications that are 
assigned to fixed slots in such a way as they would also occupy a position in the Home 
Screen area. For example if "Messages" occupies a fixed position on the home screen the 
theme should set the position of messages so that it does not occupy any of the free slots. 
This prevents messages from appearing twice on the home screen. 

[00115] Figure 10 illustrates the concept of a Home Screen area inside Organize 
Applications, in accordance with an embodiment of the present disclosure. The area in 
light grey represents the slots which are available on the home screen and the applications 
that currently occupy them. 

[00116] The applications which occupy positions in the Home Screen area also occupy 
the top positions in the applications list popup. Applications which occupy slots in the 
home screen should also be accessible from the applications list because this popup can 
be launched from within any application via a convenience key mapping. 
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[001 17] Preferably, an application which is hidden is not moveable to a position in the 
Home Screen area of Organize Applications. This is to prevent hidden applications from 
occupying a slot on the home screen. Likewise, applications which occupy a position in 
the Home Screen area of Organize Applications are not hideable. 

[00118] If the home screen skin contains configurable application slots as described, 
these are configured through the organize applications screen. The contents of the home 
screen application slots is based on the items at the top of the application menu order. If 
there are 5 slots, then the 5 applications at the top of the list would be populated into 
these slots. The organize applications screen indicates how many of the applications 
appear on the home screen by drawing a themeable region underneath the icons that fill 
the available slots. This region has a read-only label at the top that says "Home Screen". 
So if a skin has 2 slots, the top 2 icons appear over this region. If it has 5 slots, then the 
top 5 appear over this region. 

[00119] Figure 1 1 shows in a detailed block diagram a example of a preferred 
handheld device 1002 adapted in accordance with an embodiment that may be used as an 
electronic device having message and organization system functions and a home screen 
GUI as described. Handheld device 1002 is preferably a two-way communication device 
having at least voice and advanced data communication capabilities, including the 
capability to communicate with other computer systems. Depending on the functionality 
provided by handheld device 1002, it may be referred to as a data messaging device, a 
two-way pager, a cellular telephone with data messaging capabilities, a wireless Internet 
appliance, or a data communication device (with or without telephony capabilities). 
Handheld device 1 002 may communicate with any one of a plurality of base station 
transceiver systems (not shown) within its geographic coverage area. 

[00120] Handheld device 1002 will normally incorporate a communication subsystem 
101 1, which includes a receiver 1012, a transmitter 1014, and associated components, 
such as one or more (preferably embedded or internal) antenna elements 1016 and 1018, 
local oscillators (LOs) 1013, and a processing module such as a digital signal processor 
(DSP) 1020. As will be apparent to those skilled in field of communications, particular 
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design of communication subsystem 101 1 depends on the communication network in 
which handheld device 1002 is intended to operate. 

[0012 1 ] Handheld device 1 002 may send and receive communication signals over the 
network after required network registration or activation procedures have been 
completed. Signals received by antenna 1016 through the network are input to receiver 
1012, which may perform such common receiver functions as signal amplification, 
frequency down conversion, filtering, channel selection, and analog-to-digital (A/D) 
conversion. A/D conversion of a received signal allows more complex communication 
functions such as demodulation and decoding to be performed in DSP 1020. In a similar 
manner, signals to be transmitted are processed, including modulation and encoding, for 
example, by DSP 1020. These DSP-processed signals are input to transmitter 1014 for 
digital-to-analog (D/A) conversion, frequency up conversion, filtering, amplification and 
transmission over communication network via antenna 1018. DSP 1020 not only 
processes communication signals, but also provides for receiver and transmitter control. 
For example, the gains applied to communication signals in receiver 1012 and transmitter 
1014 may be adaptively controlled through automatic gain control algorithms 
implemented in DSP 1020. 

[00122] Network access is associated with a subscriber or user of handheld device 
1002, and therefore handheld device 1002 comprises a memory module 1062, memory 
module card or a Removable User Identity Module (R-UIM), to be inserted in or 
connected to an interface 1 064 in order to operate in the network. Alternatively, memory 
module 1062 may be a non-volatile memory that is programmed with configuration data 
by a service provider so that mobile station 1002 may operate in the network. Since 
handheld device 1002 is a mobile battery-powered device, it also includes a battery 
interface 1054 for receiving one or more rechargeable batteries 1056. Such a battery 
1056 provides electrical power to most if not all electrical circuitry in handheld device 
1002, and battery interface 1054 provides for a mechanical and electrical connection for 
it. The battery interface 1054 is coupled to a regulator that provides power V+ to all of 
the circuitry. 



-41 - 



! 



WO 2007/131359 



PCT/CA2007/000864 



[00123] Handheld device 1002 includes a microprocessor 1038 that controls overall 
operation of mobile station 1002. Communication functions, including at least data and 
voice communications, are performed through communication subsystem 1011. 
Microprocessor 1038 also interacts with additional device subsystems such as a display 
1022, a flash memory 1024, a random access memory (RAM) 1026, auxiliary 
input/output (I/O) subsystems 1028, a serial port 1030, a keyboard 1032, a speaker 1034, 
a microphone 1036, a short-range communications subsystem 1040, and any other device 
subsystems generally designated at 1042. Some of the subsystems shown perform 
communication-related functions, whereas other subsystems may provide "resident" or 
on-device functions. Notably, some subsystems, such as keyboard 1032 and display 
1 022, for example, may be used for both communication-related functions, such as 
entering a text message for transmission over a communication network, and device- 
resident functions such as a calculator or task list. Operating system software used by 
microprocessor 1038 is preferably stored in a persistent store such as flash memory 1024, 
which may alternatively be a read-only memory (ROM) or similar storage element (not 
shown). Those skilled in the art will appreciate that the operating system, specific device 
applications, or parts thereof, may be temporarily loaded into a volatile store such as 
RAM 1026. 

[00124] Microprocessor 1 038, in addition to its operating system functions, preferably 
enables execution of software applications on handheld device 1002. A predetermined 
set of applications that control basic device operations, including at least data and voice 
communication applications, will normally be installed on handheld device 1002 during 
its manufacture. A preferred application that may be loaded onto handheld device 1002 
may be a personal information manager (PIM) application having the ability to organize 
and manage data items relating to a user such as, but not limited to, e-mail, calendar 
events, voice mails, appointments, and task items. Naturally, one or more memory stores 
are available on handheld device 1002 and memory module 1062 to facilitate storage of 
PIM data items and other information. 

[00125] The PIM application preferably has the ability to send and receive data items 
via the wireless network. In a preferred embodiment, PIM data items are seamlessly 
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integrated, synchronized, and updated via the wireless network, with the mobile station 
user's corresponding data items stored and/or associated with a host computer system 
thereby creating a mirrored host computer on handheld device 1 002 with respect to such 
items. This is especially advantageous where the host computer system is the mobile 
station user's office or enterprise computer system. Additional applications may also be 
loaded onto handheld device 1002 through network, an auxiliary I/O subsystem 1028, 
serial port 1030, short-range communications subsystem 1040, or any other suitable 
subsystem 1042, and installed by a user in RAM 1 026 or preferably a non- volatile store 
(not shown) for execution by microprocessor 1038. Such flexibility in application 
installation increases the functionality of handheld device 1002 and may provide 
enhanced on-device functions, communication-related functions, or both. For example, 
secure communication applications may enable electronic commerce functions and other 
such financial transactions to be performed using handheld device 1002. 

[00126] In a data communication mode, a received signal such as a text message, an e- 
mail message, or web page download will be processed by communication subsystem 
101 1 and input to microprocessor 1038. Microprocessor 1038 will preferably further 
process the signal for output to display 1022 or alternatively to auxiliary I/O device 1028. 
A user of handheld device 1002 may also compose data items, such as e-mail messages, 
for example, using keyboard 1032 in conjunction with display 1022 and possibly 
auxiliary I/O device 1028. Keyboard 1032 is preferably a complete alphanumeric 
keyboard and/or telephone-type keypad. These composed items may be transmitted over 
a communication network through communication subsystem 1011. 

[00127] For voice communications, the overall operation of handheld device 1002 is 
substantially similar, except that the received signals would be output to speaker 1034 
and signals for transmission would be generated by microphone 1036. Alternative voice 
or audio I/O subsystems, such as a voice message recording subsystem, may also be 
implemented. Although voice or audio signal output is preferably accomplished 
primarily through speaker 1034, display 1022 may also be used to provide an indication 
of the identity of a calling party, duration of a voice call, or other voice call related 
information, as some examples. 
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[00128] Serial port 1030 in Figure 1 1 is normally implemented in a personal digital 
assistant (PDA)-type communication device for which synchronization with a user's 
desktop computer as a desirable, albeit optional, component. Serial port 1030 enables a 
user to set preferences through an external device or software application and extends the 
capabilities of handheld device 1002 by providing for information or software downloads 
to handheld device 1002 other than through a wireless communication network. The 
alternate download path may, for example, be used to load an encryption key onto 
handheld device 1002 through a direct and thus reliable and trusted connection to thereby 
provide secure device communication. 

[00129] Short-range communications subsystem 1040 is an additional optional 
component that provides for communication between handheld device 1002 and different 
systems or devices, which need not necessarily be similar devices. For example, 
subsystem 1040 may include an infrared device and associated circuits and components, 
or a BluetoothTM communication module to provide for communication with similarly 
enabled systems and devices. Bluetooth™ is a registered trademark of Bluetooth SIG, 
Inc. 

[00130] Handheld device 1 002 may be configured such as via software (instructions 
and data) to provide the home screen integrated presentation of information in a GUI as 
described above. 

[00131] The system and methods according to the present patent disclosure may be 
implemented by any hardware, software or a combination of hardware and software 
having the above described functions. The software code, either in its entirety or a part 
thereof, may be stored in a computer-readable memory. Further, a computer data signal 
representing the software code which may be embedded in a carrier wave may be 
transmitted via a communication network. Such a computer-readable memory and a 
computer data signal are also within the scope of the present patent disclosure, as well as 
the hardware, software and the combination thereof. 
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[00132] While particular embodiments of the present patent disclosure have been 
shown and described, changes and modifications may be made to such embodiments 
without departing from the true scope of the patent disclosure. 
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What is claimed is: 

1 . A media engine for creating a graphical interface for an application on a device, the 
media engine comprising: 

an interaction interface for notifying the media engine of changes to the 
application; 

a renderer for rendering the graphical interface; 

a parser for parsing, from a template file, template information for controlling 

how the renderer renders the graphical interface; and 
a layout manager for optionally controlling the display of template information. 

2. The media engine as claimed in claim 1 , wherein the template information 
comprises: 

a set of data element objects; and 
a set of custom event objects. 

3. The media engine as claimed in claim 2, wherein the template information further 
comprises at least one of: 

layout manager control information for controlling how the layout manager 

controls the display of template information; and 
Tenderer control information for controlling: 

how the Tenderer renders the set of data element objects; and 
how the renderer renders the graphical interface based on at least one 
custom event of the set of custom events. 

4. The media engine as claimed in claim 3, wherein the layout manger control 
information comprises at least one of: 

information for dynamically modifying the length of at least one data element of 

the set of data elements prior to being rendered; and 
information for controlling the display of template information to the graphical 

interface that the Tenderer cannot render. 
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5. The media engine as claimed in claim 1 , further comprising an event engine for 
providing event notification to the application. 

6. The media engine as claimed in claim 1 , wherein the interaction interface comprises 
a content interaction application programming interface, API including calls for: 

updating data elements; 
notification of custom events; 
querying of new events; 
getting a new event; and 
registering an event listener. 

1. The media engine as claimed in claim 3, wherein the template file comprises a 
markup language description of: 

the set of data element objects; 

the set of custom event objects; 

the layout manager control information; and 

the renderer control information. 

8. A mobile communication device comprising: 
a display; 

an operating system; 

an input device; 

at least one application; 

at least one template file; and 

a media engine comprising: 

an interaction interface for notifying the media engine of changes to the at 

least one application ; 
a renderer for rendering the graphical interface on the display; 
a parser for parsing, from the at least one template file template 

information for controlling how the Tenderer renders the graphical 
interface on the display; and 
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a layout manager for optionally controlling the display of template 
information. 

9. The mobile communication device as claimed in claim 8, wherein the template 
information comprises: 

a set of data element objects; and 
a set of custom event objects. 

10. The mobile communication device as claimed in claim 9, wherein the template 
information further comprises at least one of: 

layout manager control information for controlling how the layout manager 

controls the display of template information; and 
renderer control information for controlling: 

how the renderer renders the set of data element objects; and 
how the renderer renders the graphical interface based on at least one 
custom event of the set of custom events. 

1 1 . The mobile communication device as claimed in claim 10, wherein the layout 
manger control information comprises at least one of: 

information for dynamically modifying the length of at least one data element of 

the set of data elements prior to being rendered; and 
information for controlling the display of template information to the graphical 

interface that the renderer cannot render. 

12. The mobile communication device as claimed in claim 9, wherein each application 
of the at least one applications comprises: 

at least one application data element; and 
application code. 

13. The mobile communication device as claimed in claim 12, wherein the application 
code comprises: 

code for modifying the at least one application data element; 
code for creating at least one application custom event; and 
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code for communicating at least one of the application data element and at least 
one of the application custom event to the media engine using the interaction 
interface. 

14. The mobile communication device as claimed in claim 13, wherein the code for 
communicating the at least one application data element and the at least one custom event 
to the media engine binds the at least one application data element to at least one data 
element object of the set of data element objects of the template information and binds 
the at least one application custom event to at least one custom event object of the set of 
custom event objects of the template information. 

15. The mobile communication device as claimed in claim 8, further comprising an 
event engine for providing event notification to the application. 

16. The mobile communication device as claimed in claim 8, wherein the interaction 
interface comprises a content interaction application programming interface, API 
including calls for: 

updating data elements; 
notification of custom events; 
querying of new events; 
getting a new event; and 
registering an event listener. 

1 7. The mobile communication device as claimed in claim 9, wherein the template file 
comprises a markup language description of: 

the set of data element objects; 

the set of custom event objects; 

the layout manager control information; and 

the Tenderer control information. 

1 8. A method of skinning an application on a device comprising: 

parsing a template file; 

storing the parsed information in a template; 
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receiving updated data element information from an application through an 

interaction interface 
updating the template with the received updated data element information; 
controlling the display of the data element information using a layout manager; 
passing the template to a renderer; and 
rendering the template as a graphical interface. 

1 9. The method as claimed in claim 1 8, wherein the template comprises: 

at least one template data element representing the data element received from the 

application; and 
at least one template event representing a custom event. 

20. The method as claimed in claim 19, further comprising: 

providing event notification to the application. 

21. A computer-readable medium storing instructions or statements for use in executing 
in a computer a method of skinning an application on a device comprising: 

parsing a template file; 

storing the parsed information in a template; 

receiving updated data element information from an application through an 

interaction interface 
updating the template with the received updated data element information; 
controlling the length of the data element information using a layout manager; 
passing the template to a renderer; and 
rendering the template as a graphical interface. 
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